This Page Is Inserted by IFW Operations 
and is not a part of the Official Record 

BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of 
the original documents submitted by the applicant. 

Defects in the images may include (but are not limited to): 

• BLACK BORDERS 

• TEXT CUT OFF AT TOP, BOTTOM OR SIDES 

• FADED TEXT 

• ILLEGIBLE TEXT 

• SKEWED/SLANTED IMAGES 

• COLORED PHOTOS 

• BLACK OR VERY BLACK AND WHITE DARK PHOTOS 

• GRAY SCALE DOCUMENTS 

IMAGES ARE BEST AVAILABLE COPY. 



As rescanning documents will not correct images, 
please do not report the images to the 
Image Problem Mailbox. 



1 

■ J 



•,•1 
'I 



(19) 



J Eur p 
Europ 
Offi e 



Eur paisch s Patentamt 
European Patent Offi e 

uropeen des brevets 



(12) 



(43) Date of publication: 

04.12.1996 Bulletin 1996/49 

(21) Application number: 96303616.5 

(22) Date of filing: 21.05.1996 



( ii) EP 0 745 961 A2 

EUROPEAN PATENT APPLICATION 

(51) int ci* G07F 7/08 



(84) 


Designated Contracting States: 


• Greenspan, Steven Lloyd 




DE FR GB 


Scotch Plains, New Jersey 07076 (US) 






• Mirville, J. Robert 


(30) 


Priority: 31.05.1995 US 455939 


Manalapan, New Jersey 07726 (US) 






• Sugla, Binay 


(71) 


Applicant: AT&T IPM Corp. 


Aberdeen, New Jersey 07747 (US) 




Coral Gables, Florida 33134 (US) 








(74) Representative: 


(72) 


Inventors: 


Buckley,- Christopher Simon Thirsk et al 


• 


Blonder, Greg E. 


Lucent Technologies, 




Summit, New Jersey 07901 (US) 


5 Mornington Road 






Woodford Green, Essex IG8 0TU (GB) 



OJ 

< 

to 
o> 

in 
o 

Q. 
LU 



(54) Transaction authorization and alert system 

(57) An automated method for alerting a customer 
that a transaction is being initiated and for authorizing 
the transaction based on a confirmation/approval by the 
customer thereto. In accordance with one illustrative 
embodiment, a request to authorize the transaction is 
received, wherein the request includes a customer iden- 
tifier; a determination is made whether to authorize the 
transaction based on the customer identifier; if the de- 
termination is to authorize the transaction, that fact is 
communicated to the customer; a confirmation thai the 
transaction should, in fact, be authorized is received 
back from the customer; and the transaction is author- 
ized in response to the customer's confirmation thereof. 
In accordance with another illustrative embodiment, a 
transaction initiated by an agent of the customer (i.e., 
the principal) is authorized by the principal when one or 
more threshold parameters that may be pre-defined by 
the principal are exceeded. A preferred method of alert- 
ing the customer and receiving a confirmation to author- 
ize the transaction back from the customer is illustrative- 
ly afforded by conventional two-way pagers. 
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and IS ' nvent,on re ' ateS ,0 3 traction authorization 

anS m ' ^ m ° re PartiCUlar ' y to a met hod 

and apparatus for using a communications system to 
alert an interested party of a recently completed trans 

party for a pending transaction. 



Background of the lnv»nt;~„ 



ml Z ° ard iden,ific ation numbers assigned to 
cred. card customers are presented to many different 
people n a variety of crcumstances - when applyfng 

store, and when making purchases over the telephone 
through the maM, or over e-mail (electronic mail) The 
largenumberofpeoplethathaveaccesstoacustome^ 

vamaoT; or"'" ^ freqU6ntV ' ed «? fraud - ^2 
vantages of us.ng credit cards, however, are substan- 
tial. The customer finds their use advantageous in that 
he o r she need not carry cash or write checks. CrlcS 

colar^ r S a ' S ° adVanta96S t0 *° Waiter - 

cTeTcard L eXamPle ' t0 Paym6nt by Check ' the 
credit card serv.ce provider ensures timely payment to 
the retal , er , regard|ess Qf when me custo V P V n to 

ba anoe on the credit card account. However. credrt 

ca d numb nUmb6rS ^ St0,en ' and « 

card numbers are often used over the telephone or 

firming the customer's identity. 

Telephone calling card numbers have security prob- 
lems sim.lartothoseof credit cards. These numbers are 
often spoken aloud or entered through a touchTone ke 

them Jh " f '° Win9 ° therS ,he Wtun«y to record 
S h 6 ect : onica,, y or b V rnere observation), and 
loS™ !? f Udu ^ nl,y use ,ne n "^ers. Another common 
source of fraud sterns from authorized usage of a credrt 
card or a telephone calling card followed by a customer 
den,a, i that he or she made the purchase l ^SZ 

inLlT' S, yy con ™»"9 access tothecredit or call- 
ing card number without more may be inadequate. Com- 
pute access to secure databases is yet another exam- 

•dentrf l e r sr/. e .,passwords)whichthro ugh legal or il.ega 
channels may become known to others, thereby allow- 
ing unauthorized access to these databases 
C nnJr° r T mechanisms for handling such security 
comrT S r t9ken adVanta 9 e of adva "ces in 
aSZ^ OTSandCOmpUtersystemstoau,oma tethe 
alerting and approval process. Most techniques which 
have heretofore attempted to address these secuZs- 
^ S ' end to significantly increase the complexity of the 
commumcat.on protocol. For example, the customer 

which if aSk6d addtti0na ' qUeS,i ° ns < the a --- to 
which ,t is expected that only the authorized party would 



know), ormay be required to provide additional informa- 
tion as a part of each transaction such as a (secret) Per- 
sona, Identification Number (P.N). Moreover, it may be 
required that such PINs be modified on a routing 

ens to make use of these types of services "e.g., crel 

Sbi.itv onh CardS) ; 1 ^ bSCOme c °™onUmit the 
•ability of the customer while increasing the liability of 

io S>h"r Ce PrOVid6r (6 - 9 - ,he Cfedit card va " d °r or tet 
usuaT ° 0m T n Unfortuna ^y- ""authorized uses 

issued 9 l Und T CXBd Until 3 P6ri0dic service W is 
issued - typ,cally, at the end of a monthly billing cycle 

and long after the fraud was perpetrated 

In addition to the above-described security issues 

SsT 0 "'^ 

~£mnfl Pr ' n T 
comp ete routine transactions without the principal's 
knowledge or approval. However, the principalis 
sa rves,herighttobealeriedto,oreventoapprors U ch 
SET! '° nS ; PartiCU ' ar,y " h " they are ^elabj non- 
qu.red when certa.n threshold parameters that are as- 
sociated with the transaction (which may, fortalte 
ss be pre-defined by the principal) are exceeded ' 

atedtrll s ^ f mechanismsfor handling such agent initi- 
ated t ransactlons have a|sQ no( taken adya 

T^l en ' n9 and appr ° Val P rocess - thereby lim- 
* SofeTr h' ^'i 0 " 8 ° f SUCh transactions For 
example, a card owner, such as a corporation (parent) 

dTbH P c^o S ch a : em K Pl ° y6e (/0Un9 8dU,t > a «™ 
ZS. ^ 96 bUS,ness (P ersona ') expenses, typ- 

rca ty places certain restrictions on the use of the card 
by the cardholdertopreventabuses. excesses orfraud 

aJhTth^fa" 5 inC lT for eXamp ' e ' «W 
a cnrl f m ° Um ° f m ° nSy that can be barged to 
tha°? a k C °: 6dit Card ' ° r ,ne numb er of transactions 
predefT £? aU H thori2edfora ««■ card numberwithha 
<o LI „ ? d P6r,0d ° f time ' Those restrictions some- 
S IIS^ 300685 ,0 Credft t0 a cardh °' d - 

PTS^I ™ need6d This clear| y def ea ^ the 
purpose of empowenng the employee or young adult 

Yet .overs, 9 htoftheuseofthosecreditcardsbytLcad 
« owners ,s still needed since the card owners are utt, 
matelyfinanoially responsible for the expenses chargS 
to those credit cards. This issue takes particular S 

so ^ S9al com Petency of minors to complete 
crel an H aC,bnS ^ re,UCtant to accept dTb or 
anlT V ^ °' P^nt from minors. Hence 
Sfi P , C Pr ° b,em °' ,he prior art is lack C ■ «ex 

and.br In Un m6ChaniSm 1 " PrinCipals lo ™Z, 
and/or approve use of a card by cardholder for non-rou 

ss tine commercial transactions. 
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Summary of the Invention 

We have recognized that the aforementioned prob- 
lems result from the inability to quickly and efficiently in- 
form the individual customer (e.g., the account holder s 
or the principal) that his or her customer identifier (e.g., 
credit/debit/calling card number, PIN, password, etc. ) 
is being used in a transaction for a particular purpose, 
and the inability of the customer to respond thereto in 
order to confirm or deny its use. Thus, in accordance 10 
with certain illustrative embodiments of the present in- 
vention, an automated method for authorizing a trans- 
action is provided in which the customer is informed of 
a pending authorization thereof, and the transaction is 
then authorized only in response to a customer confir- is 
mation. In accordance with certain other illustrative em- 
bodiments, the invention provides a method and a sys- 
tem which allow a principal to be automatically alerted 
to, and/or to promptly authorize, an agent-initiated 
transaction which may, 1or example, be deemed atypical 20 
based on a pre-stored profile specified by the principal. 

In accordance with one illustrative embodiment, a 
request to authorize a transaction is received, wherein 
the request includes a customer identifier; a determina- 
tion is made whether to authorize the transaction based 2s 
on the customer identifier; if the determination is made 
to authorize the transaction, the pending authorization 
is communicated to the customer; a confirmation that 
the transaction is, in fact, to be authorized is received 
back from the customer; and the transaction is author- 30 
ized in response to the customer's confirmation thereof. 

One approach to communicating such a determina- 
tion to authorize the transaction and to receive such a 
confirmation to authorize from the customer is illustra- * 
tively afforded by conventional two-way pagers. For ex- 35 
ample, a computer database, charged with the task of 
authorizing a transaction, may signal the customer via 
paging whenever his or her customer identifier is used. 
Along with this notification, relevant information may be 
displayed on the pager's alphanumeric (or numeric) dis- 40 
play. The customer may then respond (via the two-way 
pager) by confirming or denying the pending authoriza- 
tion. 

According to one aspect of the invention, exception 
conditions that trigger a customer's alerting or approval 45 
process may be stored in a profile specified by the cus- 
tomer. This profile associates those exception condi- 
tions to a personal communications address, such as a 
paging number or a *500" or "700" prefix telephone 
number at which the customer can be reached. For so 
credit/debit and calling card transactions, exception 
conditions may be caused, for example, by a request for 
credit amount (or number of transactions) above thresh- 
old parameters pre-imposed by the card owner for the 
use of the card, or breach of other conditions pre-de- ss 
fined by the card owner for the use of the card. In ac- 
cordance with the principles of the invention, the card 
owner may elect to simply r ceive the al rt message or 



to authorize/deny the charging of the xp nses to the 
card number by transmitting an approval/disapproval 
message to the card issuer as part of the card validation 
process. 

According to another aspect of the invention, a mer- 
chant may request the approval of a parent or guardian 
to a debit/credit card transaction, such as a stored-value 
smartcard : presented to the merchant by a minor alleg- 
ing to act on behalf of the parent or guardian. In that 
case, the card number, or a proxy thereof, may be used 
as a search key to retrieve the parent or guardian's pro- 
file that identifies a communications address for the par- 
ent or guardian. The transaction is approved only if an 
authorization message is received from the parent or 
guardian. 

Brief Description of the Drawings 

FIG. 1 is a telecommunication system arranged in 
accordance with the invention to allow a card owner lo 
authorize, or to be alerted to transactions charged to th 
card by a cardholder. 

FIG.. 2 illustrates an exemplary message that is 
transmitted by an automatic dialing unit at a merchant's 
location to a card issuer's validation database. 

FIG. 3 shows an illustrative table that associates 
alerting threshold parameters to card numbers. 

FIG. 4 shows an illustrative generic message that 
is transmitted by an automatic dialing unit at a mer- 
chant's location to a card owner's communications de- 
vice. 

FIG. 5 shows specific exemplary messages that 
may be transmitted by a card validation system to a card 
owner's communications device. 

FIG. 6 is a table that correlates merchant codes to 
types of commercial establishments. 

FIG. 7 shows a flow diagram outlining illustrative 
programmed instructions executed by different ele- 
ments of the communications system of FIG. 1 to re- 
ceive approval for, or to alert a credit card owner to, a 
credit card transaction initiated by a card holder in ac- 
cordance with certain illustrative embodiments of the 
present invention. 

FIG. 8 is a flow chart of illustrative programmed in- 
structions executed by various components of the com- 
munications system of FIG. 1 to receive approval from 
a parent or a guardian of a minor initiated debit card 
transaction in accordance with a first illustrative embod- 
iment of the present invention. 

FIG. 9 shows a flow chart of a credit card purchase 
transaction to which certain illustrative embodiments of 
the present invention may advantageously be applied. 

FIG. 10 shows a flow chart of an authorization proc- 
ess in accordance with a second illustrative embodi- 
ment of the present invention. 

FIG. 11 shows a flow chart of an authorization proc- 
ess in accordance with a third illustrative embodiment 
of the present jnv ntion. 
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FIG. 12 shows a flow chart of an authorization proc- 

oHhT nrT^f With 8 f ° Urth i,,uslra,ive embodiment 
of the present invention. 

FIG 1 3 shows aflow chart of a credit card purchase 
transaction to which a fifth illustrative embodiment of the 
present invention may advantageously be applied 

i„ 1 14 f ° WS 3 f ' OW Chart 0f an au,h °rization proc- 
ess m accordance with a fifth illustrative embodiment of 
the present invention. - 



Detailed Descri ptor. 
Introduction 

be .applied to many domains, the illustrative embodi- 
ed or 22 !P deta " h6rein Wi " ,ocus °" a c '*« 
card or debn card purchase transaction. In these em- 
bodiments, a cardholder, who may or may not be the 

« c£T h? credil or debit card issuer ' uses ^ cJ2 

or debrt card (or a credit card number) to instruct a re- 
tailer (a provider of a product or service) to charge a 
purchase to the given credit card account or to deb ttfhe 
ZTt? ,he r chase *"» »• 9-n debit card lc 

? e J 11 ° r dSbit number se(ves ^ a cus- 
tomer identifier to the credit card service provider (o a 
the issuer of the credit card). 

' in JrlfJ ShOW$ u. a communic ations system arranged 
T 6 W ' th C6rtain " ,u «««v° embodiments of 
the present invention to implement the principles there- 
of. The communications system of FIG. 1 includes a 
ica,ions networ k 102, a validation database 
1 06 and a paging system network 111. Communications 
network 1 02 includes one or a series of h^SSS 

fll f (V ' a " neS 130 " 1 to 13 °- N ^formation re- 

ca rd ho TrZ . feader 1 01 • S P ecifica »y. when a credrt 
card holder hands a credit card to a merchant to charge 

SET aSS ° Cia1ed with a transaction, the merchant 

the CT T ^ thr ° U9h Carti reader 101 '° read 
the credit card number, for example, off the magnetic 

unit included ,n card reader 101 dials a telephone 
number associated with a daiabase 106 of the card is- 

re™ ,0 Va,idati ° n d3tabase 1 06 a validation 

request message that is illustratively represented in 

Similarly, when the cardholder wishes to use a debit 
card such as an Automatic Teller Machine (ATM) card 

thplTT 8 Paym6nt ,0r a c °mmercial transaction, 
he merchant enters a special code into card reader 1 01 
to inmate the alerting and approval process. Thereafter, 
card reader 101 retrieves the debit card number, for ex^ 
ample, f rom the magn tic stripe on the back of the debrt 
card before prompting the cardholder for a secret code 

£n hLk"" ^ read6r 101 ,hen tr » s to valida- 
tion database 101 a validation request message that is 



illustrated in FIG. 2. 

n„ J he J™ 3583 ^ sh °wn in FIG. 2 includes a card 

cod ^of a a H reqUe f dcredrt amount202. amerchant 
code 203, and a validation request 204. When card 

PIN entered by the cardholder. Merchant code 203 is a 
field mat .dentffies the type of business from which the 
TvoS S r^ ,atedWith,hetransac,ion ' is,ransr "ttted. 

io Sttr? an ' code 203 is appended b y ™« 

reader 101 after the requested credit amount 202 has 
been entered by the merchant, and the ca lino card 

on the back of the card. The validation request field 204 

is S t 6 T Sntered by 3 merchant i *^e ap" 

ZZ h Pafty aUth ° ri2ed 10 9 ive such a PProval 

for a debrt card transaction, .n the case where the card 
ho der ,s a mmor, for example, by requesting approval 
of the transact,on from a parent or guardian ofthe minor 
20 author,2ed P ar, V). *he merchant and the debit 

voided by he minor at a later date on the ground that 
JransaS 3 *" ^ * * ^ 

25 ria t "T. r !° 8iVin9 8 va,idation request message, vali- 
ktT a r aSe106USeSCardnUmber201 asasearch 
key to perform a table look-up operation for the purpose 
^retrieving the profile associated with the card number 
When the cardholder is a minor, and the card is a stored- 
30 vTded Z T ard ' 8 paSSphrase ° r Pr°*v information pro- 

cent^dd^f^ 106 IS 3 P roc ^or-control,ed 
centralized database fac.lity which is a repository of 

ss 1 ST Pr0fi !f S f ° r a " Credit/debrt card "umbers as 
Sse ^^^r 10 1,8 CUSt0merS " ^ ,idati °" *- 
! S,9ned 10 au,hori2e transactions 
za^n mav h a K T"™ ^ ^ Such autbo n- 
Sudedln 5 r,° n 8 S6t ° f Parameters 
«> h e t wk Pr0f " eS associa «ed with the card num- 
bers. When a retneved profile does not include a re- 

ZfhT" tf ° r a ' ertin9 ° r approval ' Nation of the card 
Wh?n I I, 6 Perf0rmed in a co "ventiona. manner 
^ ala rting parameters that may re- 
qu re communications with one or more called parties 

1 r, 0 " databaSS 106 USeS one * tba AutomS S: 
aling units (ADU) 1.0-1 to no-N to dial a telephone 
number retrieved from a profile associated with a P card 

so ^J^T " F,G - 3 is an illu strative table that associ- 

Tcarfn r da / PrWa ^ reSh0,dparamete rstocred- 
rt ca d numbers. Each record in the table of FIG. 3 is a 
profile i for a credit card number that is used to determine 

Tard nuZ " ^ transactio " s «*-9- to that credit 
cardnumberareproc ssed. The table of FIG 3includes 

2T' S Pame fi6,d 301 ; a Card •«*•' tieldS 
alert and authorization flags 303 and 304, respectively' 
atngger group of fields; a communications addressfieid 
J07, a no-answer-credit threshold field 309- and a no- 
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answ r-transaction threshold field 310. Cardholder's 
name field 301 stores the name of a card holder asso- 
ciated with a particular card number. The cardholder's 
name field may contain, for example, the first and last 
name of the cardholder (as shown for the first and third 
record) or the first name (or nickname) of the cardholder 
(as shown for the second and fourth record). Credit card 
number 302 is used as a search key in the table lookup 
operation mentioned above, to retrieve the profile asso- 
ciated with that card number. The alert flag field 303 in- 
dicates that the card owner is to be notified, although 
possibly only under certain conditions. Such notification 
may be required, for example, when processing of the 
transaction would either cause certain conditions pre- 
defined for the use of the card to be breached, or a 
threshold parameter to be exceeded. The approval flag 
field 304 alerts the card issuer that credit card transac- 
tions that violate pre-established conditions need to be 
authorized by the card owner as part of the card valida- 
tion process. These pre-established conditions may be 
p re-selected by the card owner, or they may be condi- 
tions imposed by the card issuer. The trigger group of 
fields depicted in FIG. 3 illustratively shows different pa- 
rameters which cause a card owner to be notified when 
those parameters exceed certain pre-defined thresh- 
olds. The "conditions 0 field 305 shows restrictions pre- 
selected by the card owners for use of their credit cards. 
For example, the first record indicates that the card own- 
er wishes to be alerted whenever a cardholder charges 
more than one hundred (100) dollars to the credit card 
number. The third record illustrates that the card owner 
wishes to authorize any credit card transaction for more 
than three hundred dollars. By contrast, the owner of the 
credit card number associated with the third record 
wishes to be alerted whenever that card is used at com- 
mercial establishments associated with specific mer- 
chant codes. Some card issuers assign distinct mer- 
chant codes to commercial establishments, such as 
bars, hotels and liquor stores, thereby allowing credit 
card transactions at those establishments to be easily 
identified. 

Other restrictions that may be imposed by a card 
owner may include, for example, the "maximum number 
of transactions" field 306 which defines an upper limit 
on the number of transactions that can be charged to a 
credit card number within a predetermined period of 
time. For example, the second record indicates thai the 
card owner's approval is required to validate a credit 
card transaction when more than three credit card trans- 
actions have already been processed for that credit card 
number within a twenty-four (24) hour period. Such a 
condition may be useful for example, in detecting fraud- 
ulent use of a stolen credit card. When a transaction 
threshold number is used as a parameter for processing 
a credit card transaction, the transaction count r field 
307 is incremented by 1 (one) very time a credit card 
transaction is processed. The transaction count r field 
307 is reset to "0" after the predetermined period (e.g., 



24 hours) has xpired. It will be appreciated that only a 
limited number of restrictions and/or authorizations are 
shown in FIG. 3 for ease of explanation, even though 
many other restrictions, obvious to those of ordinary skill 
5 in the art, may be requested by card owners or card is- 
suers for inclusion in the profile of FIG. 3. 

Whenever a card owner is to be notified of a condi- 
tion-breaching credit card transaction, the communica- 
tions address field 308 may be used to identify a tele- 
io phone number or an electronic mail address at which 
the card owner can be reached. Preferably, the commu- 
nications address field stores a pager number associat- 
ed with a communications carrier which provides paging 
service on a nationwide basis to contact, for example, 
*5 the card owners associated with the first and the fourth 
record. Alternatively, a personal telephone number, 
such as a "500" or a "700" prefix number may be used 
as a reach number for a card owner, such as the card 
owner associated with the second and third record 
zo shown in FIG. 3. As another alternative, an electronic 
mail address may be used which, in various illustrative 
embodiments, may be either an address to which con- 
ventional, electronic mail may be sent or an electronic 
address for use in other forms of electronic signaling 
?5 such as, for example, a direct message communicated 
to the computer screen of a logged-on user or an inter- 
active electronic two-way communication mechanism 
(e.g., a "chat" or talk" program). . 

Also included in the profile of FIG. 3 is no-answer- 
30 credit threshold field 309 and no-answer-transaction 
threshold field 310. Those fields identify respectively, 
the maximum amount of credit that can be approved, 
and the maximum number of permissible transactions 
within a given period of time, when the card owner can- 
3S not be reached by the communications system of FIG. 
1. When the card owner does not wish any transactions 
to be authorized when he or she cannot be reached, 
then those fields are set to zero. 

When the cost associated with the commercial 
40 transaction is charged to a debit card, as opposed to a 
credit card, only the card holder's name field 301, the 
card number field 302 and the communications address 
field 308 are of particular relevance since the request 
for approval is initiated by the merchant and the com- 
4 5 mercial transact ion is not completed when the debit card 
holder cannot be reached. 

Referring back to FIG. 1, when a transaction re- 
quest message, such as the one illustrated in FIG. 2, is 
received by validation database 106, the latter uses a) 
50 the information included in that message, and b) the re- 
trieved profile associated with the card number in that 
message to determine whether at least one card owner 
pre-imposed condition has been breached (or a card 
owner pre-defined thr shold has been xc eded). If so, 
ss validation database 106 fetches the communications 
address of the credit card owner and any other appro- 
priate information to format an authorization request 
and/or alert message that is transmitted to the card own- 
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r. One such message is illustrated in FIG 4 which 
shows a card holder's name field 40! , a display field 402 
and a f.eld 403 that is populated by an entryin the table 
Nlustrated,nFIG.5.The C ardho«der'snameispopuLted 

Shh f na T f iS inC ' Uded in ,he P rofile ret "eved by s 
val.dat.on database 106. Field 402 is a display field that 
always contains the two words -Credit Card ■ Held 403 
.s populated by one of the entries in the table of FIG 5 

501 Xp tab t I? 6 ' 5 Sh ° WS three se ? arate e "tries 
SL^S . re P resenIin 9 Cerent sections of io 
three different messages. Each entry is comprised 
mainly -of display information and one field that is popu- 
lated based on the particular condition that has been 
breached or the specific threshold that has been ex- 
ceeded For example, when the requested credit « 
amount for the transaction exceeds the charging limit 
pre-selected by the card owner, field 505 will be popu- 
lated by the difference between the maximum charging 
amount and the requested credit amount. Similarly 
when valuation of a card number for a transaction would 20 
cause the maximum number of transactions per day 
pre-selected by the card owner to be exceeded, the con- 
22 ? ' he,ransaction counter field is moved into field 
506. Likewise, when the card holder attempts to charge 
to a credit card number the expenses related to the pur- 2s 
chase of an item from a commercial establishment that 
is associated with a prohibited merchant code, that code 
is translated to one of the establishment type entries 
shown in the table of FIG. 6. That table correlates each 
merchant code to a particular type of commercial estab- 30 
hshment. For example, hypothetical merchant code 
1 2 *1' S f ss ° cia,ed wi <h «quor stores, while fictitious 
merchant code 4567 is mapped to hotels and motels 
Thus, once a merchant code is to a commercial estab- 

507^ FIG "I enlrV ' th3t Bntry iS SimP ' y ^ to fie,d 35 

By populating field 403 of FIG. 4 with one of the en- 
tries in FIG. 5, a complete message is formulated for 
transm 1S sK)n to the card owner. Thereafter, validation 

£E2£ . re !T eS co ~ ic *™s address in 40 
ra t w c,? S6nd ,0 the card owner the "message illus- 

ri?,r iaan * a ^ diaiin 9 u "« s ^cted 

from ADU 110-1 to ADU 110-N. The latter are arranged 
a) to initiate phone calls by dialing telephone numbers 
ec^romvalito 4S 
hose calls to other communications devices upon de- 

\7n?, *lT b3Ck S ' 9nal ,rom ,ne card °wner. ADU 
110-1 to 110-N are also designed to terminate the call if 
no feedback signal is received after a predetermined pe- 
nod of time. K £o 

If the communications address is a personal tele- 
phone number, such as a -500- or "700" prefix number 
(shown, for example, in the third record of FIG. 3). then 
database 106 transmits the message illustrated in FIG 
4 to Interactive Voice Response System (IVRS) 1 25 be- ss 
tore send.ng the communications address of the card 
owner to an idle ADU. Upon receiving the number dialed 
dy ADU 110-1, for example, communications network 



102 translates the "500" or "700" prefix tel phone 
number to a Plain Old Telephone Service (POTS) tele- 
phone number at which the card owner can be reached 

ZZ U ^°' 1 dSteCtS 3 ,eedback ^ '™ the 
card owner, it bridges the call (via line 140) to Interactive 

Voice Response System (I VRS) 125 that delivers the 

message of FIG. 4 in audio form to the card owner at 

telephone set 145, for example. Specifically, I VRS 125 

n™ r0Ce T ,ha ' 6XeCU,es ^"-speech synthesis 
programmed instructions designed to use ASCII input 
such as one of the messages shown in FIG. 4, to gen- 
erate a read aloud" audio rendition of that ASCII input 
•n a machine synthesized voice. IVRS 125 is also ar- 
ranged to prompt a card owner to provide some input to 
approve or disapprove a particular transaction For ex- 
ample a card owner may be prompted to enter a "1 " on 
a telephone dialpad to approve a transaction, or a "2" 
on the dialpad to disapprove the transaction. Also in- 
cluded in IVRS 125 is a means to respond to touch-tone 
commands from a caller . In particular, IVRS 125 is ar- 
ranged to translate the Dual Tone Multi-Frequency (DT- 

T1 S T1 feCeiVed ,r ° m ,he owner to a machine- 
readable format, such as ASCII, that is recognizable by 
validation database 106. Alternatively. IVRS 125 may 
include a word recognition unit that is arranged to output 
digitally recorded words, such as the messages in fIg 
5. to prompt a card owner for particular information that 

L C ah n ^ rt :n« t0 C ASC,l ,0tmat f ° r 10 va lidation 

database 106. Furthermore, in order to insure that the 
person approving the transaction is the card owner, as 
opposed to an impostor. IVRS 125 may also include a 
speaker recognition unit that stores templates of pre- 
recorded digitized voice messages of the card owner 
ttiat are compared to any input received from the called 
party to certify that the Veal" card owner is the person 
approving the transaction. 

If the communications address is a paging tele- 
phone number, then one of the ADUs 110-1 to 110-N 
eta s the paging telephone number to initiate a call to 
that paging telephone number for the purpose of deliv- 
e f r ?hl° ne ^ ,,he messa 9 es of F| G. 4 topagerdevice 1 35 
In, nT TZ Ca " iS r ° Uted ° Ver «™munica- 
5Tl tc S k M? 2 , WhiCh US6S ° ne of the Modulators 
120-1 to 120-N to transform the received message into 
proper signaling format for delivery to paging system 
ne work 111 which may be, for example, a satellrte 
based nationwide paging service network Alternatively 
paging system network 111 may be a cellular communis 

3 a 74" e, 7 rk ° raPersonal Communications Servic- 
es (PCS) network. Paging system network 111 includes 
a base station (not shown) that receives the dialed 
number along with the message of FIG. 5. The base sta- - 

22T iden,if ' eS 3 PartiCU ' ar ,requenc y associated 
with that pag,ng telephone number to code the receiv d 

message as a series of pulses represented by a carrier 

that ,s modulated on that frequency lor delivery to pager 

135. The latter converts the pulses into a series of bytes 

representing the message of FIG. 5. Thereafter, pager 
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1 35 emits a loud beep to signal the card owner of an 
incoming message. Alternatively, pager 1 35 could be a 
vibrating pager which silently alerts the card owner of 
the incoming message through a vibration signal gen- 
erated therein in response to the reception of a mes- s 
sage. 

When the incoming message is an alert signal from 
validation database 1 06, pager 1 35 can be any commer- 
cially available paging device with a small screenfor dis- 
playing the message of FIG. 4. However, if an approval/ to 
disapproval response is requested by validation data- 
base 1 06, pager 1 06 may advantageously be a two-way 
paging device, such as the device available from Mobile 
Telecommunications Technology Inc. of Jackson, Mis- 
sissippi. In that case, the card owner transmits an ap- is 
proval/disapproval message by entering a pre-defined 
code in the two-way pager. The pre-defined code is then 
transmitted to validation database 106 via paging sys- 
tem network 111. The pre-defined code is received by 
one of the demodulators 120-1 to 120-N which demod- 20 
ulates the signals associated with the received code for 
presentation to validation database 106. Alternatively, 
pager 135 may be a one-way pager. In this case, if an 
approval/disapproval response is requested by valida- 
tion database 106, the card owner may communicate 25 
an approval/disapproval message to validation data- 
base 106 by other means, such as with use of a con- 
ventional telephone, for example. 

A first illustrative embodiment 30 

FIG. 7 shows a flow diagram in accordance with cer- 
tain illustrative embodiments of the present invention 
outlining programmed instructions executed by different 
elements of the communications system of FIG. 1 to re- 35 
ceive an approval from a credit card owner for, or to alert 
a credit card owner of, a credit card transaction initiated 
by a card holder. The process shown in FIG. 7 is initiated 
in step 701 when validation database 1 06 receives a val- 
idation request for a credit card number. As mentioned *o 
above, the request for approval may be received in the 
form of a data message, such as the one illustrated in 
FIG. 2. Upon receiving the credit card number, validation 
database 106 uses the received credit card number as 
a search key in an attempt to retrieve a profile for the 45 
credit card number. If no profile is available in the vali- 
dation database for the credit card number, as deter- 
mined in step 702, validation database returns an "un- 
authorized transaction" message to card reader 101 via 
communications network 102. When validation data- so 
base 1 06 is able to retrieve a profile for the card number, 
the profile is analyzed in step 704 to determine whether 
the requested credit amount or the type of transaction, 
for example, triggers any alerting or requ st for approval 
conditions. If no such conditions are triggered, validation ss 
database 106 proceeds with the validation process in a 
conventional manner. Otherwise, in step 706, validation 
database 1 06 ascertains whether the card owner is only 



to be ai rted when the pre-defined condition is encoun- 
tered. If so, validation database 106 retrieves from the 
profile the card owner's communications address to 
which the alerting message is sent, as indicated in step 
707. Thereafter, validation database 106 proceeds with 
the validation process in a conventional manner. 

When the profile retrieved by validation database 
1 06 indicates that the card owner is to approve the credit 
card transaction (such as the one requested by the card 
holder) validation database 1 06 formulates a request for 
approval message (using appropriate entries in FIG. 4 
and FIG. 5) for transmission to the card owner, as indi- 
cated in step 708. As mentioned above, the request for 
approval message may be delivered in the form of a tel- 
ephone call or a paging message. After the transmission 
of the message, validation database waits for a re- 
sponse from the card owner. When validation database 
determines, in step 709, that no response is forthcoming 
after a pre-defined period of time has expired, validation 
database 106, in step 711, assesses whether the re- 
quested credit amount exceeds the no-answer-credit 
threshold. As indicated earlier, the no-answer-credit 
threshold is afield in the profile for a card number which 
stores the maximum amount of credit that can be ap- 
proved for a credit card transaction when the credit card 
owner cannot be reached by the communications sys- 
tem of FIG. 1. If the requested credit amount exceeds 
the no-answer-credit threshold, as determined in step 
711, then validation database 1 06 returns an "unauthor- 
ized transaction" message to card reader 1 01 . If the re- 
quested credit amount does not exceed the no-answer- 
credit threshold, the content of the transaction counter 
field in the profile is compared to the no-answer-trans- 
action threshold to determine whether this threshold has 
been exceeded. If so, validation database 106 returns 
an invalid card message to card reader 1 01 , as indicated 
in step 705. If neither of the no-answer-thresholds has 
been exceeded, validation database 106 completes the 
validation process in a conventional manner, as indicat- 
ed in step 703. 

When validation database 106 receives a response 
from the card owner within a pre-defined period of time, 
as determined in step 709 : validation database 1 06 then 
assesses whether the response indicates approval of 
the transaction by the card owner. If so, validation data- 
base completes the validation process in a conventional 
manner, as indicated in step 705. Optionally, the card- 
holder may be required to provide a secret code that 
matches a similar code included in the response re- 
ceived from the card owner before the transaction is au- 
thorized. If a disapproval response is received from the 
card owner, validation database 106 returns an "unau- 
thorized transaction" message to card reader 101. 

FIG. 8 is a flow chart outlining instructions per- 
formed by the elements of the illustrative communica- 
tions system of FIG. 1 to validate a debit card transaction 
in accordance with a first illustrative embodiment of the 
present invention. The process depicted in FIG. 8 is in- 
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itiated in step 801 when validation database 106 re- 
ceives a debit card number and a password entered by 
a minor card holder. Validation database 106 launches 
a query on its storage devices to determine, in step 802, 
whether a profile can be retrieved for the received card 
number. If no profile is found, validation database 106 
transmits an "unauthorized transaction" message to 
card reader 101, as indicated in step 803. Upon retriev- 
ing a profile for the card number, validation database 
106 formulates a message using one of the entries of 
FIG. 4 for transmission to the card owner. Thereafter, 
validation database 106 waits a pre-defined amount of 
time to determine whether a response is received from 
the card owner. If the pre-defined amount of time expires 
before a response is received from the card owner, val- 
idation database 106 returns an 'unauthorized transac- 
tion" message to card reader 101, as indicated in step 
803. When a response indicative of the card owner's ap- 
proval of the transaction is received from the card owner, 
as determined in step 806, validation database 1 06 pro^ 
ceeds with the validation process in a conventional man- 
ner, as indicated in step 807. If the card owner sends a 
message disapproving the debit card transaction, vali- 
dation database 106 sends an "unauthorized transac- 
tion" message to card issuer 101, as indicated in step 
803. 

In other illustrative embodiments of the present in- 
vention, the authorization of a transaction may need to 
be approved by more than one party. For example, if the 
charge account is a corporate account and the amount 
of the charge is over a certain predefined threshold, it 
may be required that two authorized parties (e.g., cor- 
porate executives) approve the transaction. This is anal- 
ogous, for example, to the common requirement that 
corporate checks over a certain amount {e.g., $1,000) 
include two authorized signatures to be valid. Similarly, 
if the transaction involves, for example, the dispensing 
of medications in a hospital (see below), it may be de- 
sirable that both the patient's doctor and the hospital's 
pharmacist approve the treatment. In these cases, step 
806 of FIG. 8 is modified to determine whether all parties 
which are required to approve the transaction have done 



so. 



A second illustrative embodiment 

FIG. 9 shows a flow chart of a credit card purchase 
transaction to which certain illustrative embodiments of 
the present invention may advantageously be applied. 
The transaction is initiated by a cardholder (i.e., the cus- 
tomer) who instructs a retailer to charge a purchase to 
a given credit card account (step 11). This instruction 
usually takes the form of providing a credit card or a 
credit card number to the retailer. This transaction may 
occur with the customer and the retail r co-present and 
in real-time, while the customer is waiting. In this case, 
the timeliness with which the authorization process is 
completed is clearly of great importance, since the rel- 



vant parties are awaiting such authorization before 
they may proceed with other endeavors. (For example, 
they may be waiting so that the retailer may hand over 
the goods to the customer or provide a service thereto.) 
5 Thus, the communication to the customer and a confir- 
mation or denial of authorization by the customer should 
advantageously occur quickly. For this reason, the use 
of two-way pagers is preferred forthis type of application 
of the principals of the present invention. 
10 in alternative applications, the customer may have 
instructed the retailer (or an agent of the retailer) in per- 
son or via some communication mechanism (e.g., a 
phone, mail, facsimile or electronic mail) at a time prior 
to the initiation of the transaction. Such instructions 
is might cover an immediate one-time purchase, a future 
purchase (e.g., the goods or service may not be imme- 
diately available) or a series of purchases to occur over 
a period of time. In cases such as these where the cus- 
tomer and the retailer are not co-present, the parties 
20 most typically do not require the authorization to be com- 
pleted before they may proceed with other endeavors. 
That is, it may be acceptable in these cases that the au- 
thorization process be completed over a longer period 
of time such as, for example, several hours or even a 
2S day. In these cases, therefore, other less immediate 
communications mechanisms may be used, such as 
those. provided by conventional telephones, e-mail, or, 
in some circumstances, even physical mail. 

In any event, the retailer's typical response to such 
so instructions is to signal a transaction processing center 
(or a network of such centers) which is associated with 
the credit card service provider that a particular custom- 
er (identified by his or her credit card number) wishes to 
purchase goods or services of a particular value. Thus, 
35 the retailer requests an authorization for the charge from 
the transaction processing center (step 12). Typically, 
this request is initiated by swiping the credit card through 
an automated card reader (such as card reader 101 of 
FIG. 1) which reads the magnetic stripe on the credit 
40 card, dials the transaction processing center, sends the 
relevant information thereto and receives either an au- 
thorization code or a denial in response therefrom. The 
information transmitted to the transaction processing 
center typically includes the credit card number, the 
^5 amount of the contemplated purchase, and the retailer's 
store identification code (e.g., card number 201, re- 
quested credit amount 202, and merchant code 203 of 
FIG. 2, respectively). The retailer then waits for an au- 
thorization from the transaction processing center which 
50 represents that the charge will be underwritten (i.e., in- 
sured) by the credit card service provider. This authori- 
zation is typically sent to the retailer in the form of an 
authorization code which identifies the transaction and 
canth r by be used to verify that the authorization proc- 
55 ess was properly adhered to by the retailer. One typical 
reason for denial, on the other hand, is that the balance 
on the customer's account has exce ded (or, if the given 
purchase were authorized would exceed) a predeter- 
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min d credit limit associated with the customer's ac- 
count. In accordance with certain illustrative embodi- 
ments of present invention, another reason for denial is 
the lack of the receipt of an appropriate confirmation (or 
the receipt of an explicit denial) by the customer whose 
account is to be charged. 

At the transaction processing center, the authoriza- 
tion process is performed automatically by a computer 
based system comprising, inter alia, a database (e.g., 
validation database 106 of FIG. 1) containing account 
information for each credit card subscriber (step 13). 
That is, such a system automatically makes the decision 
whether to authorize or deny the transaction — no hu- 
man intervention is typically required at the transaction 
processing center. If the transaction is authorized (de- 
cision 14), as is typically indicated by the appearance of 
the authorization code on the display of the retailer's 
card reader, the retailer is thereby authorized by the 
credit card issuer to accept the charge for the purchase. 
Thus, the charge is accepted and the transaction is com- 
pleted (step 15). If, on the other hand the transaction is 
denied by the transaction processing center (typically 
indicated by the appearance of a denial code on the card 
reader's display), the retailer denies the charge and ter- 
minates the transaction (step 16). 

FIG. 10 shows a flow chart of an automated author- 
ization process which may be used to implement step 
1 3 of the process of FIG. 9 in accordance with a second 
illustrative embodiment of the present invention. The 
process of FIG. 10 is illustratively executed by a com- 
puter system at the transaction processing center in re- 
sponse to each received request for the authorization of 
a transaction. The received authorization request (typi- 
cally transmitted by an automated card reader at the re- 
tailer's location such as card reader 101 of FIG. 1) in- 
cludes, in particular, a customer identifier (i.e., the credit 
card number) and may, for example, also include the 
amount of the proposed purchase and the retailer's 
store identification code (step 20). Based on the cus- 
tomer identifier, a database (such as validation data- 
base 106 of FIG. 1) is consulted to determine whether 
the transaction should be authorized (steps 21 and 22). 
For example, the database may include account bal- 
ance and credit limit information indicating that the cus- 
tomer's account balance is not permitted to exceed a 
given credit limit. In such a case, the system will deter- 
mine that the transaction should not be authorized it the 
sum of the account balance and the amount of the pur- 
chase to be authorized exceeds the credit limit. In addi- 
tion, invalid or (known to be) stolen credit cards obvi- 
ously should not be authorized. 

If it is determined. from the analysis of step 22 that 
the purchase should not be authorized for some reason 
(decision 23), the system will format a denial code (step 
24). If, on the other hand, th re is no basis for denying 
the transaction, the system will, in accordance with the 
principles of the present invention, make an attempt to 
have the (tentative) authorization confirmed by the cus- 



tomer. In particular, and in accordance with a s cond 
illustrative embodiment thereof, the system will auto- 
matically page the customer (using, for example pager 
135 of FIG. 1), supplying to him or her any relevant in- 
s formation concerning the purchase (step 25). For exam- 
ple, the system might supply the customer with an iden- 
tity of the retailer and/or the amount of the purchase, in 
order to enable the customer to more accurately ensure 
that the transaction to be authorized is, in fact, the one 
io he or she is presently undertaking, or, alternatively, that 
the transaction is one being undertaken by an agent and 
the principal (i.e., the customer) approves thereof. The 
customer's pager number (i.e., the telephone number 
which is used to communicate with the pager) may, for 
is example, be stored in the database and associated with 
the customer's account, as is shown in FIG. 3. 

Once the customer has been paged, the system of 
the second illustrative embodiment waits for a confirma- 
tion from the customer which may be supplied with use 
20 of the customer's two-way pager (step 26). If the cus- 
tomer responds with an appropriate confirmation (deci- 
sion 27), the system generates, formats and stores an 
authorization code which will enable the transaction to 
be completed. If, on the other hand, the customer does 
25 not confirm the transaction (e.g., if no response is re- 
ceived from the customer within a predetermined 
amount of time), the system formats a denial code (step 
24). After either a denial code or an authorization code 
has been formatted, it is sent to the retailer (e.g.., to card 
30 reader 101 of FIG. 1) who originally submitted the au- 
thorization request (step 29). 

A Third Illustrative Embodiment 

FIG. 11 shows a flow chart of an automated author- 
ization process which may be used to implement step 
13 of the process of FIG. 1 in accordance with a third 
illustrative embodiment of the present invention. As can 
be seen from the figure, the illustrative process of FIG. 
11 is identical to the illustrative process shown in FIG. 
10 except that decision 27, which determined whether 
a confirmation was received from the customer is re- 
placed by decision 30, which determines whether a de- 
nial is received from the customer. Other embodiments 
of the present invention may combine those shown in 
FIG. 10 and FIG. 11 by accepting either a confirmation 
or a denial from the customer. In such a case, the default 
(i.e., timeout) criterion may be either an assumed con- 
firmation or an assumed denial. 

A Fourth Illustrative Embodiment 

FIG. 1 2 shows a flow chart of an authorization proc- 
ess which may be used to impl ment st p 1 3 of the proc- 
ess of FIG. 9 in accordance with a fourth illustrative em- 
bodiment of the present invention. This fourth embodi- 
ment may advantageously be employed when the cus- 
tomer has only a one-way (as opposed to a two-way) 
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pager, since it allows for the customer's confirmation to 
be communicated indirectly through the retailer Specif- 
ically, the illustrative process of FIG. 12 is identical to 
that of the illustrative embodiment of FIG. 10 and FIG. 
11 except in the mechanism by which the customer con- 
firmation is requested and received. 

In particular, when decision 23 determines that it is 
okay to authorize the transaction, the illustrative system 
of this fourth embodiment generates a confirmation 
code and supplies that code to the customer via his or 
her (one-way) pager (steps 41 and 42). The supplied 
confirmation code may, for example, be randomly gen- 
erated so as not to be predictable. In this manner, the 
confirmation code will be known only to the customer 
(and not, for example, to a fraudulent user of the cus- 
tomer's credit card number who is not in possession of 
the customer's pager). The confirmation code may then 
be used to indirectly confirm the authorization. For ex- 
ample, where the customer is making a face-to-face pur- 
chase in a store, the customer may provide the confir- 
mation code supplied by the transaction processing 
center to the retailer, who may, in turn, provide that con- 
firmation code back to the transaction processing cent- 
er. This latter step may be performed, for example, with 
use of the automated card reader which is already in 
communication with the transaction processing center. 

Thus, after the illustrative process of FIG. 12 has 
supplied the confirmation code to the customer, step 43 
waits for a responsive input which includes a (return) 
confirmation code (e.g., from the automated card read- 
er). Then, the confirmation code which was supplied for 
the given transaction is compared to the confirmation 
code that was received (decision 44) to ensure that the 
customer is, in fact, providing a proper confirmation of 
the authorization. If the supplied confirmation code 
matches the received confirmation code, the system au- 
thorizes the transaction (steps 28 and 29). If they do not 
match, or if the system receives no responsive confir- 
mation code after a predetermined amount of time has 
elapsed, the transaction is denied (steps 24 and 29). 



A Fifth Illustrative Embodiment 

FIG. 1 3 shows a flow chart of a credit card purchase 
transaction to which a fifth illustrative embodiment of the 
present invention may advantageously be applied. This 
fifth embodiment eliminates the need for performing 
multiple communications at the time of purchase. That 
is, the extra time that may otherwise be required to page 
the customer and receive a confirmation or denial of the 
pending authorization are not needed when this fifth il- 
lustrative embodiment is employed. 

Priortothe initiation of the transaction itself, the cus- 
tomer requests and receives a confirmation code for use 
in a specifically identified subsequent transaction (steps 
51 and 52). This confirmation code, which may, for ex- 
ample, be randomly generated, will be known only to the 
customer who intends to execute the specific transac- 



tion (e.g., make a particular purchase), or, alternatively, 
to an agent of the customer (i.e., the principal) to whom 
the customer has communicated the given confirmation 
code. The specific transaction may, for example, be 
s identified based on the retailer's store identification code 
(such as merchant code 203 of FIG. 2) or other identi- 
fying indicia of the retailer. Then, when the purchase is 
initiated, the customer (or the principal's informed 
agent) provides the previously received confirmation 
to code to the retailer, who, in turn, provides the confirma- 
tion code to the transaction processing center which 
performs the automated authorization process (steps 
53-55). The automated authorization system can then 
use the received confirmation code in a manner similar 
« to that of the fourth illustrative embodiment shown in 
FIG. 12 for purposes of confirming an authorization of 
the transaction. Note that since the two-way communi- 
cation process of steps 51 and 52 need not occur at the 
time (or at the location) of the purchase but, rather, may 
20 precede the transaction by a substantial amount of time, 
a wide variety of communications devices (in addition to 
one-way or two-way pagers) may advantageously be 
used in realizing the fifth illustrative embodiment. 

FIG. 14 shows a flow chart of an automated author- 
2S ization process which may be used to implement step 
55 of the process of FIG. 13 in accordance with the fifth 
illustrative embodiment of the present invention. As de- 
scribed above, upon the receipt of a customer's request 
for a confirmation code to be used in executing a specific 
so (future) transaction, the illustrative authorization system 
generates and supplies a confirmation code to the cus- 
tomer. In addition to its being supplied to the customer, 
however, this confirmation code is associated with the 
customer identifier and, for example, the retailer store 
3S identification code, and this data is then stored in the 
transaction processing center database (e.g., validation 
database 106 of FIG. 1 ) for later retrieval - that is, when 
the identified transaction is actually executed. Thus, up- 
on a request for authorization of the given transaction, 
^o the illustrative process of FIG. 14 retrieves the previous- 
ly supplied confirmation code from the database based 
on the customer identifier and the retailer store identifi- 
cation code (steps 61 and 62). Then, after it is deter- 
mined that the transaction should (otherwise) be author- 
45 ized, the system verifies that the confirmation code re- 
ceived with the request tor authorization matches the 
confirmation code previously supplied to the customer 
(decision 63). If they do in fact match, the authorization 
may be confirmed (steps 28 and 29) 
so . 

A Sixth Illustrative Embodiment 



In accordance with a sixth illustrative embodiment 
of the present inv ntion, a confirmation code may be 
ss provided to a customer without the customer making a 
specific request ther for. This embodiment may be ad- 
vantageously applied to a credit card purchase transac- 
tion in a similar manner to the fifth illustrative embodi- 
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ment described above. In particular, the flow chart 
shown in FIG. 1 3 may be modified by removing step 51 
therefrom Then, instead of the customer requesting and 
receiving a confirmation code for use in a specifically 
identified subsequent transaction, the customer (auto- 
matically) receives a new confirmation after each trans- 
action and/or periodically (e.g., each morning) for use 
in his or her next transaction. By limiting the use of the 
given confirmation code to, for example, a single trans- 
action, the advantages of the present invention in pro- 
tecting against fraudulent transactions is obtained, while 
no direct communication from the customer to the trans- 
action processing center is required. Thus : for example, 
as in the case of the fourth and fifth illustrative embod- 
iments, one-way pagers may advantageously be used. 
Moreover, the use of a confirmation code which does 
not match the last previously supplied confirmation code 
but, rather, matches one used in a previous transaction 
' may well be indicative of fraud. 

Although a number of specific embodiments of this 
invention have been shown and described herein, it is 
to be understood that these embodiments are merely 
illustrative of the many possible specific arrangements 
which can be devised in application of the principles of 
the invention. Numerous and varied other arrangements 
can be devised in accordance with these principles by 
those of ordinary skill in the art without departing from 
the spirit and scope of the invention. For example, al- 
though the embodiments described above have fo- 
cused on a credit card purchase transaction, it will be 
obvious to those of ordinary skill in the art that the prin- 
ciples ot the present invention may be applied to a wide 
variety of transactions including, but not limited to, tele- 
phone calling card transactions, banking transactions 
including those using PINs, stock and commodity trad- 
ing transactions, and secure access transactions such 
as computer access transactions based on computer 
passwords. In addition, the principals of the present in- 
vention may be applied to numerous other types of se- 
cure access transactions such as physical access (i.e., 
entry) transactions including those used for purposes of 
inventory control. For example, an entry door to a secure 
room (e.g., a hospital's medication room) or to a secure 
facility may be locked by an electronic locking system 
(e.g., combination keypad or card access entry) which 
is electronically linked to a central facility such as the 
transaction processing center described above. Then, 
any attempt to enter the room or facility may be made 
subject to confirmation in accordance with the principals 
of the present invention. 

In addition, although the above embodiments fo- 
cused primarily on communication via wireless paging 
devices (e.g., one-way or two-way pagers), it will be ob- 
vious to those skilled in the art that many other commu- 
nications mechanisms may be used instead of, or in ad- 
dition to, wireless paging devices. These mechanisms 
include, for xample, cellular t lephones, conventional 
wired telephones, personal comput rs, etc. 
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Claims 

1 . An automated method for authorizing a transaction, 
said transaction based on a customer identifier as- 

5 sociated with a customer, the method comprising 
the steps of: 

receiving a request to authorize said transac- 
tion, said request including said customer iden- 
io tifier; 

determining, in response to said request and 
based on said customer identifier, whether to 
authorize said transaction; 
if said determining step determines that said 
transaction is to be authorized, communicating 
said determination to said customer; 
receiving a communication from said customer 
confirming that said customer consents to said 
transaction being authorized; and 
authorizing said transaction in response to said 
communication received from said customer. 

2. An automated method for authorizing a transaction, 
said transaction based on a customer identifier as- 
sociated with a customer, the method comprising 
the steps of: 

receiving a request to authorize said transac- 
tion, said request including said customer iden- 
tifier; 

determining, in response to said request and 
based on said customer identifier, whether to 
authorize said transaction; 
if said determining step determines that said 
transaction is to be authorized, communicating 
said determination to said customer; and deter- 
mining whether a communication indicating 
that said transaction is not to be authorized is 
received within a given amount of time from 
said customer; and 

authorizing said transaction if said communica- 
tion from said customer is not received within 
said given amount of time. 

3. The method of claim I or 2 wherein said step of com- 
municating said determination to said customer 
comprises transmitting signals representative of 
said determination to a wireless telecommunica- 
tions receiver. 

4. The method of claim 3 wherein said wireless tele- 
communications receiver comprises a display and 
wherein said step of communicating said determi- 
nation to said customer comprises communicating 
said customer identifier to said customer. 

5. The method of claim 3 wherein said wireless tele- 
communications receiver comprises a display and 
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wherein said step of communicating said d termi- 
nation to said customer comprises communicating 
an identity of said provider to said customer. 

The method of claim 3 wherein said wireless tele- 
communications receiver comprises a two-way 
pager and wherein said communication from said 
customer confirming that said customer consents 
to said transaction being authorized is transmitted 
by said customer with use of said two-way pager. 
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An automated method for authorizing a transaction, 
said transaction based on a customer identifier as- 
sociated with a customer, the method comprising 
the steps of: is 



to said customer a confirmation code for use in 
completing execution of said transaction; 
receiving a communication comprising said 
confirmation code; and 

authorizing said transaction in response to said 
received confirmation code matching said con- 
firmation code communicated to said customer. 

The method of claim 7 or 10 wherein said step of 
communicating to said customer said confirmation 
code comprises encoding said confirmation code to 
provide a secure communication thereof. 



communicating to said customer a confirmation 
code for use in executing said transaction; 
receiving a request to authorize said transac- 
tion, said request including said customer iden 
trfier and said confirmation code; 
determining, in response to said request, based 
on said customer identifier, and based on 
whether said received confirmation code 
matches said confirmation code communicated 
to said customer, whether to authorize said 
transaction; 

authorizing said transaction if said determining 
step determines that said transaction is to be 
authorized. 
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1 2. The method of claim 1 , 2, 7 or 1 0 wherein said trans- 
action comprises a sales transaction and wherein 
said customer identifier comprises a credit card 
number. 

1 3. The method of claim 1 , 2, 7 or 1 0 wherein said trans- 
action comprises placing a telephone call and 
wherein said customer identifier comprises a tele- 
phone calling card number. 

1 4. The method of claim 1 , 2, 7 or 1 0 wherein said trans- 
action comprises a banking transaction and where- 
in said customer identifier comprises a bank card 
number. 



30 



8. The method of claim 7 wherein said step of commu- 
nicating to said customer a confirmation code for 
use in executing said transaction is performed in re- 
sponse to receiving a communication from said cus- 35 
tomer indicating that said customer desires to exe- 
cute said transaction. 
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9. The method of claim 7 further comprising the step 
of communicating a second confirmation code to 
said customer after authorizing said transaction, 
said second confirmation code for use in executing 
a second transaction subsequent to said transac- 
tion and being different from said confirmation code. 

1 0. An automated method for authorizing a transaction, 
said transaction based on a customer identifier as- 
sociated with a customer, the method comprising 
the steps of: 

receiving a request to authorize said transac- 
tion, said request including said customer iden- 
tifier; 

determining, in response to said request and 
based on said custom r identifier, whether to 
authorize said transaction; 
if said determining step determines that said 
transaction is to be authorized, communicating 
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The method of claim 1 , 2, 7 or 1 0 wherein said cus- 
tomer identifier comprises a Personal Identification 
Number. 

The method of claim 7 or 10 wherein said step of 
communicating said confirmation code to said cus- 
tomer comprises transmitting a signal representa- 
tive of said confirmation code to a wireless telecom- 
munications receiver. 



17. The method of claim 3 or 16 wherein said wireless 
telecommunications receiver comprises a pager. 

18. An automated system for use in authorizing a trans- 
action, said transaction based on a customer iden- 
tifier associated with a customer, the system com- 
prising: 

a receiver adapted to receive a request to au- 
thorize said transaction, said request including 
said customer identifier; 
means for determining, in response to said re- 
quest and based on said customer identifier, 
whether to authorize said transaction; 
a transmitter adapted to communicate said de- 
termination to said customer if said means for 
determining determines that said transaction is 
to be authorized; 

a rec iver adapted to receive a communication 
from said customer confirming that said cus- 
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tomer consents to said transaction b ing au- 
thorized; and 

means for authorizing said transaction in re- 
sponse to said communication received from 
said customer. 

1 9. An automated system for use in authorizing a trans- 
action, said transaction based on a customer iden- 
tifier associated with a customer, the system com- 
prising: 

a receiver adapted to receive a request to au- 
thorize said transaction, said request including 
said customer identifier; 
means for determining, in response to said re- 
quest and based on said customer identifier, 
whether to authorize said transaction; 
a transmitter adapted to communicate said de- 
termination to said customer it said means for 
determining determines that said transaction is 
to be authorized; 

a timer adapted to determine whether a com- 
munication indicating that said transaction is 
not to be authorized is received within a given 
amount of time from said customer; and 
means for authorizing said transaction if said 
communication from said customer is not re- 
ceived within said given amount of time. 

20. An automated system for use in authorizing a trans- 
action, said transaction based on a customer iden- 
tifier associated with a customer, the system com- 
prising: 

a receiver adapted to receive a communication 
from said customer indicating that said custom- 
er desires to execute said transaction; 
a transmitter adapted to communicate to said 
customer a confirmation code for use in execut- 
ing said transaction; 

a receiver adapted to receive a request .to au- 
thorize said transaction, said request including 
said customer identifier and said confirmation 
code; 

means for determining, in response to said re- 
quest, based on said customer identifier, and 
based on whether said received confirmation 
code matches said confirmation code commu- 
nicated to said customer, whether to authorize 
said transaction; and 

means for authorizing said transaction if said 
means for determining determines that said 
transaction is to be authorized. 

21. An automated system for use in authorizing a trans- 
action, said transaction based on a customer iden- 
tifier associated with a customer, the system com- 
prising: 



a rec iv r adapted to receive a r qu st to au- 
thorize said transaction, said request including 
said customer identifier; 
means for determining, in response to said re- 

s quest and based on said customer identifier, 

whether to authorize said transaction; •■ 
a transmitter adapted to communicate to said 
customer a confirmation code for use in com- 
pleting execution of said transaction if said 

10 means for determining determines that said 

transaction is to be authorized; 
a receiver adapted to receive a communication 
comprising said confirmation code; and 
means for authorizing said transaction in re- 

1S sponse to said received confirmation code 

matching said confirmation code communicat- 
ed to said customer. 

22. A method of processing a transaction, the method 
20 comprising the steps of: 

receiving information associated with a trans- 
action initiated by an agent of a principal; 
retrieving a profile based on said information 
25 associated with said transaction; 

comparing at least a portion of said information 
to data included in said profile; and 
in response to said comparison, notifying said 
principal of said transaction. 

30 

23. The method of claim 22 wherein said notifying step 
further includes the step of transmitting a message 
to said principal to request approval for the trans- 
action. 

35 

24. The method of claim 23 further comprising the steps 

of: . 

receiving an approval signal from said principal; 
40 and 

in response to receiving said approval signal, 
authorizing said transaction. 

25. The method of claim 24 wherein the approval signal 
45 from the principal is transmitted from a paging de- 
vice which received the notification in response to 
the comparison. 

26. The method of claim 23 further comprising the steps 
so of: 

receiving a disapproval signal from said princi- 
pal; and 

in r sponse to rec iving said disapproval sig- 
55 nal, invalidating said transaction. 

27. The method of claim 23 lurther comprising the step 
of invalidating said transaction when no signal is re- 
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ceived from said principal in response to said re- 
quest for approval message. 

28. The method of claim 22 wherein said comparing 
step further includes the step of determining wheth- 
er parameters included in said second subset of in- 
formation exceed threshold values represented by 
said data included in said profile. 

29. A system for processing a transaction, the system 
comprising: 

a database which receives information associ- 
ated with a transaction initiated by an agent of 
a principal and which stores a profile defined 
by said principal; 

a processor which a) retrieves said profile from 
said database based on said information asso- 
ciated with said transaction, and b) compares 
at least a portion of said information to data in- 
cluded in said profile; and 
a network over which a notification signal is 
transmitted to said principal in response to said 
comparison. 

30. The system of claim 29 wherein said notification sig- 
nal includes a message requesting approval of the 
transaction. 

31. The system of claim 30 further comprising: 

an end-user device from which an approval sig- 
nal is transmitted by said principal to said data- 
base; and 

means responsive to receiving said approval 
signal at said database, for authorizing said 
transaction. 

32. The system of claim 31 further comprising a paging 
device which a) receives the notification signal in 
response to the comparison, and b) transmits the 
approval signal from the principal. 

33. The system of claim 30 further comprising: 

an end-user device from which a disapproval 
signal is transmitted by said principal to said da- 
tabase; and 

means responsive to receiving said disapprov- 
al signal at said database, for invalidating said 
transaction. 



ther includes means for determining whether pa- 
rameters included in said second subset of informa- 
tion exceed threshold values represented by said 
data included in said profile. 
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34. The system of claim 30 further comprising means 
for invalidating said transaction when no signal is 

r ceived from said principal in response to said re- 55 
quest for approval message. 

35. The system of claim 29 wherein said processor fur- 
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(54) Transaction authorization and alert system 

(57) An automated method for alerting a customer 
that a transaction is being initiated and for authorizing 
the transaction based on a confirmation/approval by the 
customer thereto. In accordance with one illustrative 
embodiment, a request to authorize the transaction is 
received, wherein the request includes a customer iden- 
tifier; a determination is made whether to authorize the 
transaction based on the customer identifier if the de- 
termination is to authorize the transaction, that fact is 
communicated to the customer; a confirmation that the 
transaction should, in fact, be authorized is received 
back from the customer; and the transaction is author- 
ized in response to the customer's confirmation thereof. 
In accordance with another illustrative embodiment, a 
transaction initiated by an agent of the customer (/.©., 
the principal) is authorized by the principal when one or 
more threshold parameters that may be pre-defined by 
the principal are exceeded. A preferred method of alert- 
ing the customer and receiving a confirmation to author- 
ize the transaction backf rom the customer is illustrative- 
ly afforded by conventional two-way pagers. 
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